The invention relates generally to the field of telecommunications switching systems and more particularly to a software application in a switch that determines how to process calls entering the switch.
An example of a switching system to which the present invention applies is described in U.S. Pat. No. 5,544,163, Expandable Telecommunications System, the contents of which are incorporated by reference herein. A telecommunication switching node described therein has line cards with multiple ports connected to subscriber""s telephone lines or to other devices such as PSTN trunks. The switching node also includes a switch/matrix card and at least two system buses for switching calls received on one port to another port in the system. One of these buses is an incoming bus that passes messages from the line cards to the matrix card and the other is an outgoing bus which transmits messages from the matrix card to the line cards. In order to perform switching on calls, the switching node receives information from and transmits information to line card ports over the system buses at predetermined times known as time slots. Each time slot generally corresponds with a port on the switch. The time slots assigned to each port and the software applications that manage calls on those time slots are generally termed a xe2x80x9cchannel.xe2x80x9d
Overall control of the system is exercised by the host, i.e., a group of software applications that typically reside on a computer. The switching nodes are interconnected by an internodal switching network. A second network termed the xe2x80x9chost network,xe2x80x9d interconnects the switching nodes and the host computer for supervisory control. Examples of the host supervisory applications include call setup and tear down applications and applications that incorporate ancillary services such as call forwarding and call waiting.
The host, the switching nodes and the line cards include their own software protocol applications which instruct them on how to handle calls. A Layer 5 (L5) protocol application in the host manages calls at the system level; Layer 3 (L3) protocol applications in the line cards handle calls at the line card level of the system and a Layer 4 protocol application (L4) i.e. a Central Call Processing(CPP) application in the switch, manages calls at the switch level. The layer 4 call-management functions include call connection and reconnection, call parking, call releasing, initiating recorded announcements, call progress tone transmissions and interactive digit collection for interactive voice response (IVR) applications. Overall supervision of these functions is provided in the host layer 5 application.
The switching node operations are limited to those call-management operations supported within the L4 application and the system operator is restricted to a menu of changes pre-defined in the L4 application. Specifically the L4 software application is hidden from the user and cannot be changed by the user.
Moreover, since the L5 host applications manage the L4 functions, when a switch receives an incoming request for service from a line card, the request must be transmitted from the L4 application to the L5 application. In response to the request, the L5 application instructs the L4 application on how to handle it. For example, in order to allocate a digital signal processor (DSP) resource to a particular call, the L4 application relays a request to the host and, in response, the L5 application instructs the L4 application on a specific connection to a DSP resource for the call. Since the L5 application is involved in directing nearly all real-time call processing on the switch, the message traffic between the switch and the host is high and if the host-to-switch link fails or if the host fails, the switch is basically rendered inoperable.
In accordance with the present invention, the L4 application in the switch is expanded to permit functions previously performed exclusively in the L5 protocol application. Moreover, the L4 application is programmable by the system operator so that the system operator may expand the pre-defined set of L4 call management operations to accommodate his call processing requirements. Overall supervision of the call-management operations was previously limited to the L5 applications. However, the ability to program the L4 application enables the system operator to decide which call processing operations will be managed by the L5 applications and which operations will be managed by the L4 application. The system operator may thus define, in the L4 application, a customized call model that instructs the switching node to manage all incoming calls, or the system operator may specify the call model on a channel by channel basis. The latter arrangement programs the switching node to use different call-processing protocols among the various channels. In addition, the system operator may either re-define or define entirely new application programming interface (API) calls for communications between the host and switching node and/or between the switching node and ports.
With the foregoing arrangement, the switching node can process calls independently from the host, thereby reducing the message traffic between the switching node and the host and also reducing the node""s dependence on the host.
In the preferred embodiment of the invention, the L4 application is separated into software objects or state machines that are separately dedicated to specific tasks for each port in the switching node. The term xe2x80x9cchannelxe2x80x9d thus encompasses the data paths between each port and the switch/matrix and the software objects in the switch/matrix that directly supervise the use of these paths. The primary software objects in the L4 application are a channel state machine (CH), a call management state machine (CM) and a physical connections management state machine (PC). Each channel in the node includes a static instance of these primary objects. The L4 application also includes secondary software objects which include an Interworking state machine, a DSP Manager state machine, a Switch Manager state machine, a Conference Manager state machine and a Distributed Router state machine.
The CH in the L4 application is a programmable protocol language (PPL) object which manages channel state information for its associated channel. Channel state information includes information about the state of each of the other objects in the channel. The CH primary functions include managing the L3 or line card channel interface for call control, managing the L5 or host call processing interface when those functions reside in the host, managing DSP resource requests and processing requests and events to and from the CM.
The L4 CM is a PPL object which manages information about the state of any call in the associated channel. The CM represents the originating channel""s view of a call and it manages the propagation of channel events (messages) to and from channels on the same switching node (local channels) and to and from channels on other switching nodes (remote channels). The CM xe2x80x98filtersxe2x80x99 incoming events from local and remote channels to make sure that those events are proper for the current call and channel states and it performs the necessary interworking functions on events received from local and remote channels. If there is a problem during a call connection, the CM xe2x80x98drivesxe2x80x99 the remote channel into the correct call state during the call re-connection. The CM sends an event to the PC when its call state and a local or remote call is ready for a voice path connection. The PC uses these events to determine whether pulse code modulation (PCM) connections should be made or broken.
The PC is a PPL software object which manages PCM switch connection information for its channel. Before a PCM connection is made, both the originating channel and the local or remote channel must be in a state where a connection is appropriate. The originating and the local or remote CM objects determine when their channels are ready for a PCM connection. The originating CM notifies its PC when it is ready for connection and the local or remote CM, through the originating CM, notifies the originating PC when the local or remote channel is ready for connection. When both of these conditions are met, the connection is made. The PC maintains information on whether a channel has a voice path connection active with another channel.
The Interworking State Machine helps to support internal routing and it gives the user the capability to specify the call model on a channel by channel basis. An instance of the Interworking object is dynamically created as it is needed for each channel. When the CM receives an event from a remote channel, the CM xe2x80x98callsxe2x80x99the Interworking State Machine, which translates the data and returns the result to the CM for processing.
The DSP Manager state machine allocates DSP resources, routes DSP requests to the appropriate DSPs and reports the results to the CH. The Switch Manager state machine and its data structure also manage simple connect and disconnect requests from the PC for all switching types, including local time slot switching and ring switching.
The Conference Manager State Machine manages conference calls by managing the DSP resources and issuing commands to the DSP resources. The conference manager also manages channel connections to the DSP. The Distributed Router state machine is a PPL object that fields requests to route information based on a number of parameters such as, incoming port, resource group and digit string in the message.
Each of the L4 objects includes an interface with parameter values that may be modified by the user. The system includes display screens which display these values and facilitate changes therein by the system operator.